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(54) Multimedia multipoint telecommunications reservation systems 

(57) Reservation controllers and reservation sys- 
tems for reservation of access to multimedia multipoint 
telecommunications servers (MCUs) are provided. The 
reservation controller establishes a reservation domain 
having a reservation request channel on which reserva- 
tion applications may be taken. An ongoing reservation 
conference is associated with the reservation domain. 
The reservation domain is preferably established within 
the ITU-T T.120 standard series requirements, with 
multipoint connection under T.122/T.125, and interface 
to profiles such as ISDN, TCP/IP, X.25, ATM, Ethernet, 
etc., under T.123. A user makes reservations for MCU 
resources by knowing the address of the reservation 
domain, attaching himself to the reservation domain, 
joining the reservation conference via establishing one 
or more transport connections, and sending the reser- 
vation request onto the reservation request channel. All 
reservation requests forwarded onto the reservation 
request channel are received and acted upon by the 
reservation controller. Reservation systems utilizing a 
plurality of reservation controllers are also disclosed, 
where the reservation controllers are part of the same 
domain, are arranged in multiple domains on a single 
level, or are arranged in hierarchical domains. Where 
more than one reservation domain is established, 
same-level or hierarchical level bridges are established. 
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Description 

BACKGROUND 

1 . Field of the Invention s 

The present invention relates broadly to multipoint 
multimedia telecommunications systems. More particu- 
larly, the present invention relates to reservation sys- 
tems for the use of multimedia multipoint servers which w 
are used in the establishment and conduct of multipoint 
multimedia conferences. 

2. State of the Art 

15 

With the increase of throughput (data rate) availa- 
ble in the telecommunications industry, and in associa- 
tion with the improvement of compression and 
decompression algorithms, the number of telecommuni- 
cation applications available to individuals and busi- 20 
nesses has increased dramatically. One of these 
applications is called "multimedia communications" 
which permits video, audio, and in some cases other 
data to be transported from one party to another or oth- 
ers. Multimedia communications can be utilized for a 25 
number of applications, and in different configurations. 
One configuration of recent interest has been multime- 
dia conferencing, where several parties can communi- 
cate in a conference style. 

In multimedia conferencing, the audio and video 30 
data is handled such that each party can see and hear 
one, several, or all of the other parties. In fact, various 
telecommunications recommendations and standards 
are presently being adopted by the ITU-T, ISO, and Bell- 
core which govern the protocols of multimedia confer- 35 
encing (see, e.g., ITU-T T.120). In the multimedia 
conferencing systems of the art (as represented by prior 
art Figure 1), the audio, video, and other data streams 
generated by a user's system 12a are multiplexed 
together directly in the encoder section of a multimedia 40 
encoder/decoder (codec) 14 located at the source/ter- 
minal 16, and transported together through the trans- 
port network 20 (now proposed in ATM format) to a 
similar "peer" codec at a remote location. The peer 
codec is either another codec 1 4 at the remote user site 45 
for a point-to-point conference, and/or a codec/switch 
24 at a multimedia bridge 26 (also called a multipoint 
control unit or MCU) for a multipoint conference. The 
multipoint control unit 26, which typically includes a 
codec/switch 24 and a controller 28, provides confer- so 
ence control (e.g., it determines the signal to be sent to 
each participant), audio mixing (bridging) and multicast- 
ing, audio level detection for conference control, video 
switching, video mixing (e.g., a quad split, or "continu- 
ous presence device" which combines multiple images 55 
for display together) when available and/or desirable, 
and video multicasting. The audio and video data exit- 
ing the MCU is multiplexed, and continues through the 
transport network 20 to the desired multimedia source 



terminals 12b, 12c. 

It will be appreciated by those skilled in the art that 
the MCU is a technically complex and expensive piece 
of equipment/system, and that use of the MCU is care- 
fully controlled and billed to the user. In addition, it will 
be appreciated that because of its expense and limited 
availability, access to the MCU is treated as a rare 
resource. Thus, in order to guarantee to a given user the 
necessary resources for a desired conference at a given 
time, the user must reserve access to the MCU in 
advance of use. Reservations are made by a "reserva- 
tion request" which typically involves a telephone call to 
an operator at the company with the MCU. In response 
to a reservation request which will often include param- 
eters such as a starting time, a duration, and resources 
necessary (e.g., bandwidth, mixing and switching, etc.), 
the operator will typically access a "reservation control- 
ler", which is typically a programmed computer, in order 
to determine whether the required resources of the 
MCU will be available at the desired time. If the 
resources are available, the operator will enter informa- 
tion into the reservation controller program related to 
the incoming request for desired connections and serv- 
ices for the given time, accept the reservation, and 
inform the applicant/user of codes (e.g., a reservation 
number) required for the conference. When the time is 
reached for the conference, the reservation controller 
will inform the MCU of the beginning of a new confer- 
ence and the precise resources reserved for that confer- 
ence. When the users wish to join the conference and 
access the MCU, the users call the operator, provide the 
reservation number, and are added to the conference, 
with the necessary resources having been already 
reserved and available. 

To date, the use of MCU's has been very limited. 
There are several reasons for this limited use. First, all 
multimedia services are extremely new, and most tele- 
communications customers have not yet invested in 
multimedia service equipment. It is expected, however, 
that the next five years will see an explosion of growth in 
the area of multimedia telecommunications. Second, 
the companies which provides multimedia equipment 
often utilize proprietary or alternative standardized 
schemes (e.g., MPEG and JPEG) which are not neces- 
sary compatible. Thus, it is often impossible for owners 
of different types of multimedia equipment to communi- 
cate with each other. Again, solutions to this problem 
are being proposed, including transcoders which are 
intended to make MPEG and JPEG equipment compat- 
ible. Third, and with respect to multipoint multimedia 
services such as conferencing, each manufacturer of an 
MCU uses its own proprietary reservation controller 
mechanism for reserving access to the MCU. Thus, 
unless each user in the conference has access to the 
same MCU, or to MCUs which are under control of the 
same reservation controller, it may be impossible for 
users to conference as desired because reservations 
requiring access to different MCUs may be impossible 
because of their control by different controllers. 



2 



3 



EP 0 794 645 A2 



4 



SUMMARY OF THE INVENTION 

It is therefore an object of the invention to provide a 
reservation controller for multimedia multipoint servers. 

It is another object of the invention to provide a s 
standardized reservation system which will permit any 
multimedia user to reserve the resources of one or more 
MCUs for a multimedia multipoint conference. 

It is a further object of the invention to provide a res- 
ervation system for multimedia multipoint servers which 10 
utilizes the environment of the T.120 protocol series in 
receiving a reservation request. 

It is an additional object of the invention to provide 
a multimedia multipoint server reservation system 
which has an established reservation domain which is 
includes one or more reservation controllers and to 
which a user can attach in order to place a reservation 
application. 

Another object of the invention is to provide an 
automatic multimedia multipoint reservation system. 20 

A further object of the invention is to provide a mul- 
timedia multipoint server reservation system with multi- 
ple reservation controllers arranged in a hierarchical 
multiple domain structure. 

An additional object of the invention is to provide a 25 
reservation domain having a reservation request chan- 
nel utilized by multiple reservation controllers of a multi- 
media multipoint server reservation system. 

Yet another object of the invention is to provide a 
server reservation system for multimedia multipoint 30 
communications with multiple reservation domains hav- 
ing continuous and/or dynamic connections. 

In accord with the objects of the invention, and 
according to a first primary aspect of the invention, a 
reservation controller for use with one or more multime- 35 
dia multipoint servers (MCUs) is provided where the 
reservation controller establishes a reservation domain 
with a reservation request channel on which reservation 
applications may be taken. In the preferred embodi- 
ment, the reservation domain is established within the 40 
T.120 standard series requirements (with the term 
"domain" being defined in ITU-T T.122, and loosely 
defined as including all members who are connected to 
a conference), with multipoint connection under 
T.122/T.125 (Multipoint Communications services), and 45 
interface to profiles such as ISDN, TCP/IP, PSDN 
(X.25), ATM, IEEE 802.3 (Ethernet) etc., under T.123 
(Transport Protocol Stack Profiles). If desired, confer- 
ence control under T. 1 24 (Generic Conference Control) 
may also be provided, although other conference con- so 
trol mechanisms can be utilized. In accord with the 
invention, and based on the T.120 series of standards, a 
reservation "domain" with a reservation request channel 
is established within T. 1 22/T. 1 25 by the reservation con- 
troller in order to collect point-to-point transport connec- 55 
tions and combine them to form a multipoint connection. 
An ongoing reservation conference is associated with 
the reservation domain. If the reservation controller 
establishes a reservation conference under T.124, the 



reservation domain is set up as part of the reservation 
conference. 

When users wish to make reservations for 
resources of the multimedia multipoint server, they must 
know the address of the reservation domain, and must 
attach themselves to the reservation domain (the term 
"attach" also being defined in T.122) and join the reser- 
vation conference. Typically, this will be accomplished 
by establishing one or more transport connections (as 
defined by ITU-T standards X.214 and X.224 which are 
hereby incorporated by reference in their entirety 
herein) between the user and the reservation controller. 
The transport connection could be established either 
utilizing X.214 and X.224, or via the use of other proto- 
cols such as X.25, TCP/IP, ATM, etc., many of which are 
defined in ITU-T T.123. At the lower layers, any type of 
protocol can be used such as Ethernet, ISDN, PPP, 
etc.) Once attached to the reservation domain, the user 
can make a reservation request by sending the reserva- 
tion request onto the reservation request channel. All 
reservation requests forwarded onto the reservation 
request channel are received and acted upon by the 
reservation controller. The reservation controller is cou- 
pled to one or more MCUs and preferably stores the 
schedules of the MCUs to which it is coupled so that it 
can properly act on the reservation request. 

In the situation where multiple reservation control- 
lers are provided, as discussed below, the user calls the 
address domain of the "local" reservation controller in 
order to attach to the reservation domain and join the 
reservation conference. Once joined to the reservation 
conference, the user can then send the reservation 
request onto the reservation request channel of the res- 
ervation domain. By utilizing the reservation request 
channel, when a reservation request which affects 
MCUs of different reservation controllers is placed on 
the channel, each affected reservation controller can 
determine whether the MCU or MCUs for which it is 
responsible is/are available as requested. Preferably, 
the resulting determination of each controller is pro- 
vided to the reservation controller of the MCU most local 
to the user for processing and forwarding to the user. 
Alternatively, each reservation controller can send infor- 
mation regarding the availability of its MCUs to the user. 

In accord with a second primary aspect of the 
invention, a reservation system is provided and includes 
a first plurality of reservation controllers which are par- 
ties to a first reservation domain; i.e., the reservation 
controllers are all coupled to a first reservation request 
channel. The reservation system may be further 
expanded by including a second plurality of reservation 
controllers which are parties to a second reservation 
domain, where one or more reservation controllers can 
act as a bridge between the different domains. The 
bridge or connection between the domains can be static 
(continuous), or dynamic (connected intermittently on 
an as-needed basis). If desired, the reservation 
domains may be hierarchical; i.e., providing different 
levels. Thus, the reservation domains may parallel the 
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local/regional/national/international telephone system, 
with first level domains relating to local MCUs, second 
level domains relating to regions (e.g., within a single 
area code); third level domains relating to countries; 
and fourth level domains relating to international confer- 5 
ences. The connections between the hierarchical 
domains can likewise be static or dynamic. It should 
also be appreciated that regardless of how the reserva- 
tion domains of the reservation system are connected, 
and whether or not they are hierarchical, the reservation w 
domains which are established are preferably estab- 
lished under the T.120 standard series requirements. 

According to additional preferred aspects of the 
invention, each user receives reservation information 
(e.g., answers to reservation requests) on the user's pri- 15 
vate channel. Also, besides utilizing a reservation 
requests channel for transmission of reservation appli- 
cations in a multi-reservation controller system, addi- 
tional channels can be provided. For example, one or 
more channels dedicated for the transmission of man- 20 
agement information between one or multiple reserva- 
tion controllers and their associated MCUs may be 
provided. Likewise, one or more channels used solely 
for the transmission of reservation data amongst the dif- 
ferent controllers may be provided. 25 

Additional objects and advantages of the invention 
will become apparent to those skilled in the art upon ref- 
erence to the detailed description taken in conjunction 
with the provided figures. 

30 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a representation of a multimedia confer- 
encing system of the prior art, including a telecommuni- 
cations network and an MCU. 35 

Figure 2 is a high level diagram showing a system 
with a plurality of users, a plurality of MCUs, and a plu- 
rality of reservation controllers. 

Figure 2a is a high level diagram showing the sys- 
tem of Figure 2 with the reservation domain and reser- 40 
vation request channel of the invention. 

Figure 3 is a diagram of the ITU-T T.120 series 
Infrastructure Recommendation modified in accord with 
the invention to show a reservation application. 

Figure 4 is a diagram of a ITU-T T.120 generic 45 
application model on which the reservation application 
of the invention is based. 

Figure 4 is a diagram of the server part of the reser- 
vation application of the invention. 

Figure 5 is a high level diagram of a single level res- so 
ervation system according to the invention. 

Figure 6 is a high level diagram of a hierarchical 
reservation system with multiple levels according to the 
invention. 

55 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Turning to Figure 2, a hypothetical telecommunica- 



tions system is shown and includes a plurality of users 
1 12a-1 121 (typically coupled to the network 20 - see Fig. 
1), a plurality of MCUs 126a-126d (typically located in 
the network), and a plurality of reservation controllers 
130a, 130b (typically coupled to and/or located at the 
MCUs). Each reservation controller 130a, 130b, is 
shown coupled to two MCUs, while each MCU is shown 
servicing three users. It will be appreciated by those 
skilled in the art that depending upon its configuration 
and the needs of the users, each MCU can service 
many more than three users; and depending upon sim- 
ilar parameters, each reservation controller can service 
more than two MCUs. However, for purposes of simplic- 
ity of understanding, two reservation controllers, four 
MCUs, and twelve users are shown. With the provided 
arrangement, it will be appreciated that if users 112c, 
112e, 112f, 112g, 112h, and 112j should wish to partic- 
ipate in a multimedia conference, the services of the 
four different MCUs 126a-126d will be required. Thus, 
the two reservation controllers 130a, 130b must be con- 
tacted to reserve appropriate access and processing of 
the MCUs. However, with the systems that presently 
exist in the art, if the MCUs and reservation controllers 
are owned and operated by different companies, it may 
be impossible to arrange such a multimedia conference. 
In addition, with the provided arrangement it is not evi- 
dent to which reservation controller the user should for- 
ward a reservation request, and how the reservation 
controllers will share the information contained in the 
request among themselves. 

As seen in Fig. 2a, and in accord with the invention, 
one of the reservation controllers 130a, 130b of the 
hypothetical telecommunications system of Fig. 2 initi- 
ates and establishes a "reservation domain" which is 
provided with (typically upon request) a "reservation 
request channel" 135; and the other of reservation con- 
trollers attaches itself to the established reservation 
domain and joins the reservation request channel 135. 
The reservation domain is associated with a "reserva- 
tion conference" (which if desired, may be pursuant to 
ITU-T T.124) and attachment to the reservation domain 
is accomplished by joining the conference. As is defined 
by ITU-T T.122 (MCS), any node (users, reservation 
controllers, MCUs, etc.) which attaches itself to a 
domain will be assigned a private channel (also called a 
"single member channel"). The private channel is nor- 
mally used as a user identifier which provides a user 
identification and serves as an address for point-to- 
point communication within the multipoint domain. How- 
ever, within T.122, another type of channel called a mul- 
ticast channel can be defined to which any number of 
nodes can be joined. The reservation channel 135 is 
such a multicast channel. 

It should be appreciated by those skilled in the art 
that any node which is attached to the domain can send 
data on any channel in the domain (the ability to send 
data being shown by dotted lines in Fig. 2a). However, 
only nodes which have joined a particular channel will 
receive the data sent on that particular channel (the 
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ability to receive data being shown by solid lines in Fig. 
2a). Thus, any node wishing to send private data to any 
other node will do so by sending this data on the private 
channel of the destination node, with representative pri- 
vate channels 147c and 147i being shown in Fig. 2a for 5 
users 1 12c and 1 12i. 

A user who wishes to make a reservation will join 
the reservation conference and must attach himself to 
the reservation domain, but will not join the reservation 
request channel. Once attached to the reservation 10 
domain, the user can attempt to place a reservation by 
sending a reservation request onto the reservation 
request channel 135. The reservation request will typi- 
cally include a plurality of multimedia conference 
parameters discussed in more detail below such as the 15 
starting time, the duration, the addresses of the users 
involved, and the resources necessary for the confer- 
ence. In addition, the user will specify his own private 
channel address for reservation confirmation. Since the 
reservation controllers 130a, 130b are party to the res- 20 
ervation domain and have joined the reservation 
request channel, the parameters placed on the reserva- 
tion request channel 135 are available to (i.e., are 
received by) the reservation controllers 130a and 130b. 

Where the set of users who will be party to the mul- 25 
timedia conference all are serviceable by a single MCU 
(such as users 1 12d, 1 12e, and 1 12f), then the reserva- 
tion controller (e.g., 130b) for that single MCU (e.g., 
MCU 126b) will make a determination as to whether the 
necessary MCU 126b resources will be available for the 30 
requested conference for the time requested. If so, the 
reservation controller 130b will confirm the reservation 
with the conference-initiating user via the private chan- 
nel of the user. Where the set of users who will be party 
to the multimedia conference are not all serviceable by 35 
a single MCU (such as users 112a, 112b, and 112g), 
but a single reservation controller (e.g., controller 130a) 
is involved, again, the reservation controller can deter- 
mine whether resources are available and can confirm 
the reservation with the conference-initiating user via 40 
the private channel of the user. However, where the set 
of users who will be party to the multimedia conference 
are serviced by multiple MCUs which are serviced by 
multiple reservation controllers, (such as users 112c, 
1 12e, and 1 12f), then the reservation controller(s) (e.g., 45 
130a, 130b) for the MCUs involved (e.g., MCUs 126a, 
126b) will make determinations as to whether the nec- 
essary resources of the MCU 126a, 126b under their 
control will be available for the requested conference for 
the time requested. so 

Determination as to the availability of MCU 
resources which are governed by multiple reservation 
controllers can be accomplished in several ways. In one 
preferred embodiment where all of the reservation con- 
trollers are joined to the reservation request channel, 55 
and they all receive every reservation request which is 
sent to the channel, each controller is programmed to 
determine the part or parts of the resources requested 
by the user which are managed by itself. Thus, each 



reservation controller can proceed to process the part of 
the request for which it is responsible (i.e., a sub- 
request). After processing their sub-requests, those res- 
ervation controllers which are not the master reserva- 
tion controller (i.e., the master being the most local 
reservation controller to the user) for the request send 
responses to the reservation controller which is the 
master for the request. After reviewing the responses, 
the master informs the user of the acceptance or refusal 
of the request on the private channel of the user, and 
informs the other reservation controllers of the result of 
the request. When a reservation is confirmed, the reser- 
vation controllers involved update their MCU resource 
files. 

In a first alternative approach, rather than having 
each reservation controller respond to the master, each 
reservation controller can directly inform the user of its 
response. The reservation process running at the user's 
terminal would then be used to gather all of the 
responses, so that the user could determine whether 
the reservation (or a portion thereof) could be accepted. 
If the resources proved to be suitable, the user would 
place a confirmation on the reservation request chan- 
nel, and the reservation controllers would update their 
MCU resource files accordingly. 

As a second alternative approach, the reservation 
controller responsible to answer the request (i.e., the 
master for the request), can communicate with the other 
reservation controller(s) and ask for the status of the 
MCU resources for which they are responsible. Upon 
gathering the information, the master can decide 
whether to accept the reservation or not, inform the user 
of the decision, and inform the other controllers so that 
they can update their MCU resource files if necessary. 

It should be appreciated that besides requesting a 
new reservation, the user will typically have the capabil- 
ity of making other requests. For example, the user 
should be able to view, cancel, and modify a previously 
accepted reservation. Furthermore, the user preferably 
should be able to place queries regarding the availability 
of resources. 

According to the preferred embodiment of the 
invention, the entire reservation system, including the 
reservation domain and the reservation request chan- 
nel are generated in accordance with and comply with 
the ITU-T T.120 series of standards (the latest versions 
of which are all hereby incorporated by reference herein 
in their entirety). T.120 and T.121 define the relationship 
between a T.12x application and the remaining T.12x 
recommendations or standards, with 7.120 defining the 
environment, and T.121 defining the Generic Applica- 
tion Model to be used with the applications which use 
T.122/T.125 (Multipoint Communications Service or 
MCS) and T.124 (Generic Conference Control or GCC). 
Therefore, to be compatible, a "reservation application" 
under T.120 must be built with respect to at least the 
T.120, T.121, and T.122/T.125 recommendations. 
Because audio and video control are not particularly 
pertinent to the reservation application, use of T.124 is 
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optional, although minimal control is required for the 
multipoint application. 

As will be appreciated from Fig. 3, and in accord 
with the T.120 infrastructure recommendations, network 
specific transport protocols are set forth in T.123 which 5 
permit interface with profiles such as Ethernet (IEEE 
802.3), TCP/IP (the Internet), X.214/X.224, ATM, etc. In 
addition, it should be appreciated that "agents" can be 
provided which will translate or otherwise transform 
commands and data of other profiles which are not part 10 
of T.123 so that interface with T.122/T.125 is possible. 

Sitting atop the T.123 interface is the MCS 
T.122/T.125 standard which governs multipoint commu- 
nications. Various multipoint applications can be imple- 
mented utilizing T.122/T.125. It should be appreciated 15 
that T 1 22/T. 1 25 is particularly desirable and suitable for 
the reservation application of the invention (shown in 
dotted lines in the applications section of Fig. 3 to indi- 
cate that the reservation application is not yet a stand- 
ard application of the ITU-T), as the reservation 20 
application of the invention utilizes multipoint communi- 
cations. In addition, as shown in Fig. 3, the GCC T.124 
standard can be provided for conference control, 
although the use of conference control under T.124 is 
not necessary for practicing the invention. If GCC is pro- 25 
vided, however, a node controller is required for gather- 
ing requests from the applications and sending them to 
the GCC. It is noted that Fig. 3 shows that MCS and 
GCC can support applications using standard applica- 
tion protocols T.12x (such as T.126 Still Image and 30 
T.127 File Transfer), as well as applications using non- 
standard protocols and applications using standard and 
non-standard protocols. 

As will be appreciated by those skilled in the art, 
and as suggested by Figure 4, the T.121 standard 35 
requires that applications include two parts: a User 
Application (UA), and one or more Application Protocol 
Entities (APEs). An APE is further divided into two ele- 
ments: an Application Resource Manager (ARM), and 
an Application Service Element (ASE). 40 

The User Application has no direct affect on inter- 
working and thus may be product and platform specific. 
The User Application relies on the services of one or 
more APEs to communicate with peer applications at 
other nodes, and does not directly communicate with 45 
the MCS (T.1 22/T. 125) and the GCC (T.124) shown in 
Fig. 4. According to a preferred embodiment of the 
invention the reservation UA is programmed to include 
the following functionalities: reservation type, address 
list, repeating and periodic conferences, help menu, so 
and input validity checking. The reservation type func- 
tionality is a program which permits the user to indicate 
whether a new reservation is being requested, or 
whether a review, change or cancellation of a prior res- 
ervation is being requested. The address list functional- 55 
ity is a program which permits and/or requires the user 
to enter a list of addresses, write cascaded lists, edit 
address lists on-line, name a list, edit a previously made 
list, label each address in the list, and specify which 



entry in the list will have chairperson/broadcaster con- 
trol. 

The UA can also specify parameters which are to 
be provided by the customer. Among the preferred cus- 
tomer-provided parameters are: account billing, number 
of conferees, conference timing, conference setup 
mode, conference mode, conference quality, physical 
channel selection, and video receiving mode. The 
account billing permits the user to enter the calling 
number or card number which is to be the billed 
account. The number of conferees who will participate 
in the conference should be fixed at reservation time 
due to resource allocation management, although the 
user should be able to modify this number before or dur- 
ing the conference, provided resources are free at the 
MCUs involved. The date, time and duration of the con- 
ference should also be fixed at reservation time due to 
resource management, with the duration also being 
alterable before or during the conference subject to 
resource availability. In conjunction with duration param- 
eter, the user may be able to specify a conference termi- 
nation mode. 

The conference setup mode is the mode used by 
the conferees to join a conference and may specify a 
parameter (whether the conference is listed or not) and 
three lists. When the parameter indicates that the con- 
ference is not listed, only the conferees specified in the 
three lists can joint the conference. Otherwise, any con- 
feree with the proper password can join the conference. 
The three lists preferably include a list of users that will 
be automatically called when the conference is created, 
a list of customers who have permission to joint the con- 
ference after it is created provided that they have the 
proper password, and a list of customers who have per- 
mission once they are conferees to invite other custom- 
ers to joint the conference. Each list can contain data or 
be empty. 

The conference mode should include the four 
known basic modes of voice-activated switching, chair- 
person control, broadcast monologue, and broadcast 
dialogue. In addition, if desired, other modes such as 
conferee's choice, automatic control, and subconferenc- 
ing can be supported. In conferee's choice, each con- 
feree can decide whom (s)he wants to see and whom 
s(he) wants to hear. In automatic control, the MCU will 
decide what must be seen by whom as well as what 
must be heard. If subconferencing is enabled, two or 
more participants to a conference will be able to initiate 
a "private" conference while they are still members of 
the initial conference. 

The conference quality parameter provided by the 
user specifies the video and audio qualities (band- 
widths) desired, as well as the bandwidth desired for 
other data. Video quality may be constrained by the 
standard (e.g., JPEG or MPEG) being used, as well as 
local resources of the conferees, network capacity, etc. 
Likewise, audio quality may be constrained by the 
standard being used, and the application (audio vs. 
voice). The physical channel selection parameter pro- 
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vided by the user allows the user to specify and identify 
which video terminals will use circuit switching to con- 
nect to the MCU and which video terminals will use pri- 
vate lines to connect the MCU. Finally, the video 
receiving mode permits the user to select whether con- 5 
ferees will receive a single video feed (e.g., of the cur- 
rent speaker) from another conferee, a merged video 
feed (e.g., a quad split or "continuous presence"), or 
multiple video feeds which permits the conferee to indi- 
vidually configure and position the incoming images. w 

Turning now to the Application Protocol Entities 
(APE) side of the T. 121 standard requirement, the Appli- 
cation Resource Manager (ARM) of the APE provides 
generic functionality common to all standardized appli- 
cation protocols, while the Application Service Ele- 15 
ments (ASEs) provide functionality specific to their 
respective application protocols. As set forth by T.121, 
an APE is characterized by the following attributes: a 
single MCS service access point (SAP); a single GCC 
SAP, a single application user ID, a single ARM, a single 20 
ASE, and a node controller SAP. 

The ARM is responsible for managing GCC and 
MCS resources on behalf of the ASEs within the APE. 
The ARM should provide the following services: 
responding to indications from the GCC (e.g., permis- 25 
sion to enroll, invoke); enrolling ASEs with the GCC; 
obtaining handles from the GCC; attaching to an MCS 
domain to obtain a single Application User ID for all 
ASEs within the APE; joining static channels; identifying 
and joining multicast channels using the GCC Registry 30 
and MCS; convening private channels and admitting 
peer ASEs to such channels; joining any private chan- 
nels to which an ASE has been admitted; identifying 
and obtaining tokens from the GCC Registry; deleting 
entries from the registry associated with any multicast 35 
channel it may have convened; invoking peer APEs at 
other nodes; and processing Application Roster reports 
to determine the negotiated Application Capability list 
and identity of peer nodes. 

The ASE provides application protocol specific 40 
functionality to the user application with resources 
obtained by the ARM. Its operation is independent of 
the type and identity of tokens and channels passed to 
it. The User Application should specify the type of 
resources to use, but not the identity of those resources. 45 
The ASE obtains the identity of resources to use from its 
ARM. 

The ASE provides the following services: sending 
and receiving application protocol -specif ic protocol data 
units (PDUs); grabbing and releasing tokens and deter- so 
mining token status using MCS; responding to GCC 
Conductor Assign and Release indications; issuing 
GCC-Conductor-Permission-Ask requests through the 
Node Controller; and responding to GCC-Conductor- 
Permission-Grant indications. 55 

According to the preferred embodiment of the 
invention, the reservation application has a protocol 
which is divided into three parts: the user (conferee) 
part which is the part which runs on the user's terminal 



and allows the user to make a reservation; the MCU 
part which runs at the MCU; and the server part which 
runs at the reservation controller and processes all the 
reservation requests. These three separate parts repre- 
sent a logical division of the protocol and not necessar- 
ily a physical one, as the physical MCU can have both 
the MCU and the server part of the protocol. In other 
words, the MCU and the reservation controller may be 
integrated physically. 

The user part of the reservation application is the 
part that runs on the user's terminal. It allows the user to 
exchange data with the reservation server in order to 
make reservations. The tasks of this part are: to estab- 
lish and maintain a MCS (T.122/T.125) connection via 
T.123 with a reservation controller; to accept, code, and 
send reservation requests and parameters of the user 
to the reservation controller via the reservation request 
channel; and to receive results from the reservation 
controller via the user's private channel and display 
them to the user. 

The MCU part of the reservation application runs 
on the MCU and allows the MCU to communicate with 
the reservation controller to inform it of the status of its 
resources. The tasks of this part are to establish and 
maintain a connection with the reservation controller, 
and to receive and answer requests from the reserva- 
tion controller regarding the status of the resources of 
the MCU and the starting of conferences. 

The server part of the reservation application is the 
part that runs an the reservation controller which is pref- 
erably embodied as a suitably programmed SUN 
SPARC STATION 5 having suitable memory (although 
other processors, computers, or work stations could be 
utilized). The server part of the reservation application 
which is shown schematically in Fig. 4a allows the con- 
troller to exchange data with the users and the MCUs in 
order to process the different requests of the users/con- 
ferees. The tasks of this server part are to: establish and 
maintain multiple simultaneous MCS connections with 
users, MCUs, and other reservation controllers (via use 
of the application resource manager 170, the MCS 172, 
and if desired, the GCC 174), thereby establishing a 
reservation domain and conference; monitor the status 
of all MCUs connected to the reservation controller, 
including notifying the MCUs of the start and the 
resources required for a conference (using the resource 
handler 182); receive, process, and accept or refuse the 
requests of the users such as new reservations, modifi- 
cations of reservations, etc. based on any desired 
acceptance algorithm (using the reservation manager 
184 and the acceptance algorithm 186); maintain a list 
of the reservations for which it is responsible (at the res- 
ervation handler 188 of Fig. 4a); and exchange data 
with other reservation controllers when a reservation 
request necessitates the use of more than one reserva- 
tion controller. It will be appreciated by those skilled in 
the art, that the algorithm for accepting or rejecting new 
reservations, or modifications of the reservations can be 
proprietary to the supplier of the reservation controller. 
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Turning now to Fig. 5, a hypothetical system with 
ten reservation controllers 230a-230j, each of which is 
respectively coupled to an MCU 226a-226j and two 
users 212a1-212j2 is seen. The reservation controllers 
of the reservation system of Fig. 5 are structured on a 
single level, in that any reservation controller can con- 
nect itself to any other reservation controller and 
exchange data with it. It should be appreciated, that in 
accordance with the invention, the single level structure 
of the system of Fig. 5 can utilize a single reservation 
domain, or multiple reservation domains. In particular, if 
all of the reservation controllers 230a-230j are attached 
to the same reservation domain, then they will all be 
joined to the same reservation request channel. Thus, 
any reservation request which is placed on the reserva- 
tion request channel will be reviewed by each reserva- 
tion controller of the system for purposes of determining 
whether its resources will be required. On the other 
hand, where numerous reservation controllers are 
being utilized, it might be advantageous to break the 
reservation controllers into more than one domain. In 
this situation, at least one of the reservation controllers 
should act as bridge by being part of two or more reser- 
vation domains. Thus, if a user should wish to establish 
a conference with conferees who would be handled by 
the reservation controller of another domain, the bridge 
controller would pass the reservation request informa- 
tion onto the reservation request channel of the other 
reservation domain so that the appropriate reservation 
controller in the other domain could address the 
request. In Figure 5, a single level, two domain system 
is seen, where reservation controllers 230a-230e are 
part of a first domain, and reservation controllers 230e- 
230j are part of the second domain. Since reservation 
controller 230e is part of both domains, it acts as the 
bridge controller. 

Turning to Figure 6, the same ten reservation con- 
trollers 230a-230j, MCUs 226a-226j, and users 212a1- 
212j2 discussed above with reference to Fig. 5 are 
seen, but they are arranged in a multiple level or hierar- 
chical architecture. In a hierarchical system, multiple 
domains are established. While many different hierar- 
chical systems can be provided, the system of Figure 6 
suggests a preferred approach where each reservation 
controller (with each controller possibly corresponding 
to a plurality of local exchanges) establishes its own res- 
ervation domain with one or more local MCUs and the 
local users. A plurality of second level reservation 
domains (each corresponding, if desired, to an area 
code) are established by providing second level reser- 
vation controllers 330a-330e which share a reservation 
request channel with one or more of the first level reser- 
vation controllers. Thus, as seen in Fig. 6, reservation 
controllers 230a and 230b are conferenced with second 
level controller 330a in a first second level reservation 
domain; reservation controllers 230c and 230d are con- 
ferenced with second level controller 330b in a second 
second level reservation domain; reservation controllers 
230e, 230f, and 230g are conferenced with second level 



controller 330c in a third second level reservation 
domain; reservation controller 230h is conferenced with 
second level controller 330d in a fourth second level 
reservation domain; and reservation controllers 230i 

5 and 230j are conferenced with second level controller 
330e in a fifth second level reservation domain. 

A third level reservation domain is shown in Fig. 
6 by the provision of a third level controller 430 which 
conferences with all of the second level reservation con- 

w trollers 330a-330e. The third level domain can corre- 
spond, if desired, to a country code. It should be 
appreciated that a fourth level (e.g., international) 
domain may also be established. In fact, by hierarchi- 
cally dividing the domains in different manners, it will be 

15 appreciated that many more than four levels can be pro- 
vided. 

The advantage of the hierarchical architecture of 
Fig. 6 over the single level architecture of Fig. 5 is that 
there is no need for a bridging reservation controller to 

20 keep large amounts of information regarding the differ- 
ent systems which it is bridging. Rather, if a reservation 
controller notes a request on the reservation request 
channel of its domain which it cannot handle, it immedi- 
ately passes that information to the reservation control- 

25 ler of the higher domain to which it is also party. 
Depending upon whether or not the information can be 
handled at that level, the reservation controller of the 
higher domain may then either pass the information to 
yet a higher domain, or back down to the appropriate 

30 lower domain. Thus, in the hierarchical architecture, the 
reservation controllers bridge different levels of domain, 
but need not keep detailed information regarding the 
higher domains. 

It should be appreciated by those skilled in the art 

35 that the architectures of Figures 5 and 6 are not neces- 
sarily exclusive of each other. In other words, it is possi- 
ble to use single level bridging reservation controllers as 
part of one or more levels of a hierarchical arrangement. 
It will also be appreciated that the architecture of the 

40 reservation application can be based on either a "con- 
tinuous connection" or a "dynamic connection" type 
arrangement. In the continuous connection arrange- 
ment, all nodes that are concerned by reservations, as 
well as the nodes that might need one time to make a 

45 reservation must be connected continuously to the res- 
ervation domain. The advantage of the continuous con- 
nection arrangement is that MCS connection time is 
minimized. With the dynamic connection arrangement, 
the nodes establish different connections based on their 

so instant needs, with connections being made each time a 
conferee has a reservation request, and connection 
being released once the processing of the request is 
terminated. With the dynamic connection arrangement, 
a connection is created (i.e., the domain is modified) for 

55 each request, and the connection is deleted (i.e., the 
domain is modified again) when the result of the request 
is known. The advantage of the dynamic connection 
arrangement is that the cost of connection is limited only 
to the time of actual usage. Again, it should be recog- 
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nized that the continuous connection and dynamic con- 
nection arrangements may be co-utilized. For example, 
the domains which include the users may be set up as 
dynamic connection reservation domains, as most 
users will not need continuous type connections and will 5 
find it expensive to keep a connection active when 
nobody is transmitting data. On the other hand, the 
domains which include only reservation controllers (and 
MCUs) may be set up as continuous connection reser- 
vation domains, as large amounts of data may be regu- w 
larly sent, and connection may be required almost 
continuously. If desired, statistical measurements may 
be made of the use of each connection and therefrom a 
decision can be made as to whether the dynamic or the 
continuous connection is most desirable for that con- 15 
nection. In fact, if desired, some connections may be 
continuous during periods of peak usage, and dynamic 
at other times. 

There have been described and illustrated herein 
multimedia multipoint telecommunications reservation 20 
systems. While particular embodiments of the invention 
have been described, it is not intended that the inven- 
tion be limited thereto, as it is intended that the invention 
be as broad in scope as the art will allow and that the 
specification be read likewise. Thus, while the invention 25 
has been described with reference to the ITU-T T.120 
family of standards, it will be appreciated that other plat- 
forms could be utilized provided that a reservation 
domain is established with a reservation request chan- 
nel to which users can connect to make a reservation 30 
request. Likewise, while the invention was described 
with reference to particular arrangements with only one 
or two MCUs coupled to each reservation controller, 
and only two or three users coupled to an MCU, it will be 
appreciated that different numbers of MCUs could be 35 
used in conjunction with a reservation controller, and 
different numbers of users could be coupled to an MCU. 
In fact, pursuant to T122/T.125, up to 65,535 connec- 
tions can be made in a single domain, although it would 
not be deemed advisable to have so many users con- 40 
nected to a single MCU. Also, while the conference con- 
trol was described with reference to T.124, it will be 
appreciated that since only minimal control is necessary 
for the reservation application (i.e., data only as 
opposed to audio/video/data), other control mecha- 45 
nisms which do not meet T.124 requirements could be 
utilized. It will therefore be appreciated by those skilled 
in the art that yet other modifications could be made to 
the provided invention without deviating from its spirit 
and scope as so claimed. so 

Claims 

1. A reservation controller for controlling access to at 
least one telecommunications multimedia 55 
multipoint control unit (MCU), comprising: 

a) means complying substantially with ITU-T 
T.122 multipoint communications service 



(MCS) protocol for establishing with multipoint 
connection a reservation domain with a reser- 
vation request channel; 

b) conference control means associated with 
said reservation domain and establishing an 
ongoing reservation conference; 

c) first interface means complying substantially 
with at least a portion of ITU-T T.123 network 
specific transport protocol for interfacing with a 
data transport profile of a user who wishes to 
make a reservation; 

d) second interface means for coupling said 
reservation controller to the at least one MCU; 

e) reservation application protocol entity 
means including means for receiving a reser- 
vation request placed on said reservation 
request channel, and means for determining 
whether the at least one MCU coupled to said 
reservation controller has sufficient resources 
to meet said reservation request, wherein 

the user makes said reservation request 
by attaching to said reservation domain, joining 
said ongoing reservation conference, and plac- 
ing said reservation request on said reserva- 
tion request channel. 

2. A reservation controller according to claim 1, 
wherein: 

said first interface means complies substan- 
tially with all of said ITU-T T.123 network spe- 
cific transport protocol and provide an 
X.214/X.224 protocol interface, an IEEE 802.3 
protocol interface, an ATM protocol interface, 
and a TCP/IP protocol interface. 

3. A reservation controller according to claim 1, 
wherein: 

said conference control means complies sub- 
stantially with at least a portion of ITU-T T.124 
generic conference control (GCC) protocol, 
and controls said ongoing reservation confer- 
ence. 

4. A reservation controller according to claim 1, 
wherein: 

said reservation controller is coupled to a plu- 
rality of MCUs, and said reservation application 
protocol entity means includes means for stor- 
ing resource schedules of said plurality of 
MCUs. 

5. A reservation controller according to claim 1, fur- 
ther comprising: 

means for sending a response regarding said 
reservation request to the user via a private 
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channel of the user. 

6. A reservation controller according to claim 1 , fur- 
ther comprising: 

5 

means for collecting information from another 
reservation controller. 

7. A reservation controller according to claim 6, 
wherein: w 

said information is a response by said the other 
reservation controller to a reservation request 
regarding an MCU coupled to the other reser- 
vation controller. is 



available to said second reservation con- 
troller when said second reservation con- 
troller is joined to said first ongoing 
reservation conference, 

third interface means for coupling said sec- 
ond reservation controller to a second 
MCU of the plurality of MCUs the 
resources of which is controlled by said 
second reservation controller, and 
second reservation application protocol 
entity means including second means for 
receiving a reservation request placed on 
said reservation request channel. 

1 0. A reservation system according to claim 9, wherein: 



8. A reservation controller according to claim 6, 
wherein: 

said information relates to a resource schedule 20 
of an MCU coupled to the other reservation 
controller. 

9. A reservation system which controls access to a 
plurality of telecommunications multimedia 25 
multipoint control units (MCUs), comprising: 

a) a first reservation controller having 

means for establishing with multipoint con- 30 
nection a first reservation domain with a 
first reservation request channel, 
conference control means associated with 
said first reservation domain and establish- 
ing a first ongoing reservation conference, 35 
first interface means for interfacing with a 
data transport profile of a user wishing to 
make a reservation, 

second interface means for coupling said 
first reservation controller to a first MCU of 40 
the plurality of MCUs the resources of 
which is controlled by said first reservation 
controller, and 

first reservation application protocol entity 
means including first means for receiving a 45 
reservation request placed on said first 
reservation request channel, and means 
for determining whether the first MCU cou- 
pled to said first reservation controller has 
sufficient resources to meet its portion of so 
said reservation request; 

b) a second reservation controller having 

means for joining said first ongoing reser- 55 
vation conference and for coupling to said 
first reservation request channel, wherein 
reservation requests of a user placed on 
said first reservation request channel are 



said second reservation controller has means 
for determining whether the second MCU cou- 
pled to said second reservation controller has 
sufficient resources to meet its portion of said 
reservation request, and means for forwarding 
a resource determination to said first reserva- 
tion controller. 

1 1. A reservation system according to claim 9, wherein: 

said second reservation controller includes 
means for sending information regarding 
resources of said second MCU to said first res- 
ervation controller. 

12. A reservation system according to claim 10, 
wherein: 

said second reservation controller has fourth 
interface means for interfacing with a data 
transport profile of another user wishing to 
make a reservation, 

13. A reservation system according to claim 12, 
wherein: 

said second reservation controller further 
includes means for establishing with multipoint 
connection a second reservation domain with a 
second reservation request channel, and sec- 
ond conference control means associated with 
said second reservation domain and establish- 
ing a second ongoing reservation conference. 

14. A reservation system according to claim 9, wherein: 

said second reservation controller further 
includes means for establishing with multipoint 
connection a second reservation domain with a 
second reservation request channel, and sec- 
ond conference control means associated with 
said second reservation domain and establish- 
ing a second ongoing reservation conference. 
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15. A reservation system according to claim 14, further 
comprising: 

a third reservation controller coupled to at least 
one of said first and second reservation 5 
domains and having, 

second means for joining at least one of 
said first and second ongoing reservation 
conferences and for coupling to at least 10 
one of said first and second reservation 
request channels, interface means for cou- 
pling said third reservation controller to a 
third MCU of the plurality of MCUs the 
resources of which is controlled by said is 
third reservation controller, and 
third reservation application protocol entity 
means including third means for receiving 
a reservation request placed on one of 
said first and second reservation request 20 
channels. 

16. A reservation system according to claim 15, 
wherein: 

25 

said first reservation domain is at a first hierar- 
chical level, and said second reservation 
domain is at a second hierarchical level. 



vation conference joins said second reserva- 
tion controller to said first ongoing conference 
on an ongoing static basis. 

21 . A reservation system according to claim 9, wherein: 

said means for establishing with multipoint con- 
nection a first reservation domain, and said 
means for joining said ongoing first reservation 
conference and for coupling to said first reser- 
vation request channel both comply substan- 
tially with ITU-T T.122 multipoint 
communications service (MCS) protocol. 

22. A reservation system according to claim 21, 
wherein: 

said first interface means complies substan- 
tially with at least a portion of ITU-T T.123 net- 
work specific transport protocol for interfacing 
with a data transport profile of a user who 
wishes to make a reservation. 



17. A reservation system according to claim 16, 30 
wherein: 



said third reservation controller is at one of said 
first and second hierarchical levels. 

35 

18. A reservation system according to claim 16, 
wherein: 



said third reservation controller is at a third 
hierarchical level, and further includes means 40 
for establishing with multipoint connection a 
third reservation domain with a third reserva- 
tion request channel, and third conference con- 
trol means associated with said third 
reservation domain and establishing a third 45 
ongoing reservation conference. 

19. A reservation system according to claim 16, 
wherein: 

50 

said means for joining said first ongoing reser- 
vation conference joins said second reserva- 
tion controller to said first ongoing conference 
on an as-needed basis. 

55 

20. A reservation system according to claim 16, 
wherein: 



said means for joining said first ongoing reser- 
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